home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c-part2 / 15756 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.9 KB

  1. Path: mayne.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.sys.hp.hpux,comp.lang.c
  4. Subject: Re: Curses Window Question
  5. Date: 21 Apr 1996 09:55:52 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4ldpaoINNkvq@mayne.ugrad.cs.ubc.ca>
  8. References: <4ldji6$1qh@loki.tor.hookup.net>
  9. NNTP-Posting-Host: mayne.ugrad.cs.ubc.ca
  10.  
  11. In article <4ldji6$1qh@loki.tor.hookup.net>,
  12. Rajendra Singh <Rajendra_Singh@msn.com> wrote:
  13. >This is the most appropriate newsgroup that I could think of to post
  14. >this query, so please, if it's not totally appropriate for me to post
  15. >it here, forgive me.
  16. >
  17. >I have an application which is written in C using curses running on
  18. >HP/UX v9.07.  I create a window, display some information in the
  19. >window, ask the user to press a key, then get rid of the window.  The
  20. >problem I'm having is that when the window goes away so does the text
  21. >that was below it, i. e. it wipes out what was on stdscr.  How can I
  22. >prevent this from happening?
  23. >
  24. >To get rid of the window I'm calling:  werase(), wrefresh(), and
  25. >delwin() in that order.
  26.  
  27. (Boy I'm still fuming over that $4.25/hr programming job ad! If I had my hands
  28. on the necks of these Jones Internet Channel people in Englewood, CO. I'd crush
  29. their vertebrae to a pulp)
  30.  
  31. Anyway, to your question:
  32.  
  33. First of all, it's quite system specific, since curses it not part of the C
  34. language. So if you ask in perhaps a UNIX newsgroup, you might get more help.
  35. You should probably join the community of ncurses developers and users, since
  36. they are actively working with curses and ncurses. Much of the expertise in
  37. this area is concentrated around the ncurses mailing list.
  38.  
  39. Secondly, it always helps if you post some code, as longs as it's not reams and
  40. reams...
  41.  
  42. Now, that aside, the reason that the region below your window which you destroy
  43. is not repainted is because curses is not a system for maintaining overlapping
  44. windows. The discipline of repainting windows is up to your application.  There
  45. is no automatic ``expose and repaint'' calculation.
  46.  
  47. First of all, calling werase() doesn't help you one bit here. There is no need
  48. to erase a window before deleting it with delwin(). All that will do is write
  49. spaces to the terminal on next update. What you want to do is simply destroy
  50. the window (or just keep it around if you will need it later), and tell curses
  51. to redraw the window below it, in this case stdscr. This normally means calling
  52. refresh() (the same as wrefresh(stdscr)). Curses does not know that the window
  53. has been obscured before, so before calling refresh() you have to mark the
  54. window for an update operation. This is done using touchwin().
  55.  
  56. So, to force an update of the stdscr, do touchwin(stdscr) followed by
  57. refresh(). This will cause it to paint over all the windows as though it came
  58. to the ``foreground''.
  59.  
  60. If you are maintaining multiple windows in a ``stacking order'', you must keep
  61. them inside your own queue. When you change the stacking order, you repaint
  62. back to front using touchwin() and wnoutrefresh() for each window (this means:
  63. update to the internal update buffer, but DON'T send updates to the physical
  64. terminal, hence the ``nout'' in the name). When this completes, you call
  65. doupdate(), which will compute the changes between what is currently in stdscr
  66. and the new image in the update buffer, and it will transmit an optimized
  67. refresh sequence to the terminal in ``one fell swoop''.  The effect is quite
  68. impressive, considering what you are working with! For example, if you raise a
  69. back window to the front, only the portion that was previously obscured will
  70. typically be redrawn, even though you redrew all the windows internally. That's
  71. because that's the only region that is different between what was on the screen
  72. before and what is in the update buffer.
  73.  
  74. On the other hand, if you call wrefresh() on each window instead, you will see
  75. the repaint taking place window by window, which takes time and looks pretty
  76. gross.
  77.